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® Network management system and relational database therefore. 

® A relational data base system useful for man- 
aging a data communications network from a central 
repository employs a novel nonstandard reference 
key along with primary and foreign keys to research, 
address, retrieve and manipulate records of func- 
tional and physical entities and attributes of nodes 
and links that form the network. 
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BACKGROUND OF THE INVErfTION 
Field of The Invention 

This invention relates generally to voice, video 
and data network nnanagennent and in particular, to 
a network nr>anagement system employing a rela- 
tionai data base repository. 

COMMUNICATION NETWORKS 

The present invention focuses on data commu- 
nication networks ranging from small networks with- 
in a single building or campus«like complex to 
largo geographically distributed networks spanning 
the nation. A network comprises network or nodal 
switches (nodes) interconnected by transmission 
links. Wire, cable, radio, satellite or fiber optic units 
form the links. 

Various modes of accessing networks exist. A 
user may have a hard-wired dedicated port into a 
switched node. Users may share an access link 
and wait to transmit when polled; or may dial into a 
particular access port. Special arrangements exist 
for users who first must access a private small 
network and then require connection to a large, 
geographically distributed network or sets of net- 
works. The small network could be a digital private 
branch exchange (PBX) with dial-in access or a 
local area network (LAN) that might operate In a 
token-passing (polling) mode or a contention 
(random) mode. 

Where interconnected networks incorporate a 
variety of data sources, the interconnections are 
done through gateways. These gateways provide 
the necessary protocol translation and interfacing 
between disparate networks of possible different bit 
rates (bandwidth) and packet-handling capabilities, 
and different architectural constructs. Gateways ex- 
ist as separate intelligent systems (nodes) or as 
embedded circuits within network switches. 

The network may deliver traffic correctly and to 
the right place, yet the system may not operate 
correctly. Each computer and each application pro- 
gram in the computer, may require a different 
communication access method aruJ protocol. Data 
must be presented to the end users In a form that 
can be recognized and manipulated. The end user 
terminal or computer must format the received 
data, regulate the data rate, control order of arrival 
etc. These tasks and others like them have nothing 
to do with the operation of the network. Software 
generally provides the added controls required at 
either end of the network. 

LAYERED COMMUNICATION ARCHITECTURES 
Layered communication architectures such as 


IBM's Systems Network Architecture (SNA) and the 
ISO Reference Model for Open Systems Intercon- 
nection (OSI) and etc. provide for sequences of 
required tasks. 

« The purpose of the layered architectures is to 

provide for reliable, timely communication between 
disparate end users. The architecture may be visu- 
alized in two groupirtgs: (1) a higher-layer grouping 
of layers that involves the setting up and maintain- 

fo ing a connection (session in SNA terms) twtween 
end users, and the syntax and semantics of the 
data exchanged, and (2) a tower grouping of layers 
that provide the network transport capability end to 
end. By presenting the present invention in a SNA 

1$ context, only background information about SNA 
win t>e discussed. 

NETWORK ADDRESSABLE UNITS (NAU'S) 

20 End user devices In a SNA network include 

terminal users, workstations, application programs, 
printers, graphics display devices, and memory 
storage devices. End user devices access a SNA 
network through access ports or connection re- 

25 source managers called logical units or LU*s. 

LU'S 

The LU'S at either end establish the session of 
30 logical connections over which end-user data is 
transported. One LU can support several end users 
and can support sessions to multiple LU*s. 

Various types of LU's carry on particular types 
, of sessions. Type 1 LU's support communication 
35 between an application program and data process- 
ing temninals; type 2 LU's support application pro- 
grams communicating with a single display termi- 
nal in an interactive mode; type 3 LU's support 
application programs communicating wittv a single 
40 printer; type 4 LU's enable data-processing termi- 
nals connected as peripheral nodes to commu- 
nicate and type 6 LU's correspond to program-to- 
program communication. 

45 PU'S AND SSCP'S 

To help in managing the nehvork. SNA em- 
ploys two other resource managers, a physical unit 
or PU. which manages the communication re- 

50 sources at a given node (these comprise the data 
links and communication channel serving the 
node), and a system services control point or 
SSCP. which manages all resources within a sub- 
set of a network called a domain. 

55 All three units (LU's, PU's and SSCP's) com- 
prise the group of network addressable units 
(NAU'S). Each unit having a unique network ad- 
dress permits addressing from anywhere within or 
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from outside me network. 

PU's. together with an SSCP that oversees 
them, ensure availability and readiness of the com- 
munication links. The SSCP helps in setting up arKi 
taking down a session, provides control and main- 
tenance support for Its domain, maintains a direc- 
tory and routing tables and communicates with the 
other SSCPs across the network. 

Interconnecting nodes form the SNA network. 
Each node contains one PU. responsible for man- 
agement of its links and channels. It may contain 
many LU's. SNA has four kinds of nodes, each 
designated as a different PU type. PU type 1. is 
made up of low-function terminals and controllers. 
PU type 2 consists of high function terminals, dis- 
tributed processors, and cluster controllers (devices 
which control terminals, display systems and other 
lower-function devices). These two groups of nodes 
form peripheral nodes. These nodes do not partici- 
pate directly in the operation of transport network. 
They attach to another group of nodes called sub- 
area nodes. 

The sub-area nodes include PU type 4 nodes 
which are communication controllers running on a 
Network Ck)ntrol Program (NCP) and PU type 5 
nodes which are usually host computers. These 
type 4 and 5 PU*s are interconnected to form the 
transport network. The SSCP resides in a PU type 
5. One SSCP controls a domain made up of PU 
type 4. 2 and 1 nodes. A PU type 4 may reside in 
two domains. Although a node generally corre- 
sponds to a system or device, it is possible to have 
more than one node (multiple PU's) in a given 
physical device. 


suited for representing fundamental real-world 
ideas necessary for structuring the databases that 
an enterprise uses. 

Data base designers have employed data 

6 structure diagrams (not flow diagrams) to present 
general pictures of record types (entities) and rela- 
tionships of tables represented by boxes in the 
diagram. Usually, a relationship between any two 
record types is not symmetrical. An entity refers to 

10 any object (a person, place or thing) or an event 
(purchase date of the computer, date of employ- 
ment). Henoe, the designers have developed var- 
ious symbols to show zero-tO"one. one-to-one, 
zero-to-many, one-to-many, manyto-many type re- 

16 lationships between entities. 

The relational data model provides three fea- 
tures: structure, integrity, and manipulation. From a 
user viewpoint, the structure of the relational model 
represents a collection of tables called relations. 

20 

STRUCTURE 

The rows of the tables called tuples or records 
represent instances or occurrences of the entity or 

25 relationship. The columns or fields of the tables 
show the attributes of the entity. A domain of the 
attribute equals the set of all possible values that 
can appear in a given column. Hence, a table 
associates with another table by attribute values in 

90 their respective columns that come from a common 
domain. If the attribute has unique and defined 
(non-null) values for each tuple, the attribute may 
serve as a primary key of one of the entities 
involved. 

35 


RELATIONAL DATA BASES 

.Relational data bases stored in a computer on 
direct-access storage (such as disks) permit the 
central processing unit (CPU) of a computer to 
exploit the relationships within a reasonable span of 
time. Multiple users can share the same accurate, 
consistent, up-to-date information efficiently from 
remote and local locations. 

In the corporate world, data suffer from in- 
compatibilities across different computer platforms, 
different peripheral devices, and manipulations of 
non-data base software packages in different and 
un-integrated formats. Some corporations which 
have transferred their manual operations into com- 
puterized systems to offer economical, high speed, 
accurate data processing have created various dif- 
ficulties for users to obtain, integrate, or transform 
their databases. 

The integration issue fostered generalized data 
base managomeni systems (DBMS). The DBMS, in 
turn, required a formal way to express the data's 
logical structure and use. Hence, data models re- 
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INTEGRITY 

Referential integrity provides a set of rules for 
defining the relationship t)etween two tables, a 

40 "parent* or a "dependent" table. The parent table 
defines the domain of the dependent table. 

The first rule of referential integrity dictates 
how to define the parent table. Step (1) Include an 
attribute in the parent table that uniquely identifies 

45 each row in the table. Sequentially assigned num- 
t>ers achieves uniqueness. The assigned numt>er 
becomes a unique identifier. This attribute cannot 
be null. Step (2) Define this attribute as the 
'Primary Key" for the table. Step (3) Define a 

so unique index for the table that uses the attribute. 
These three steps complete the definition of the 
parent table and its referential integrity compo- 
nents. A dependent table can now be defined. 
The second rule dictates how to define the 

55 dependent table's relationship to the parent table. 
Step (1) Include in the definition of the dependent 
table an attribute which matches, in both size and 
format, the primary key of the parent table. This 
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comptetds the dafiniton of the referential integrity 
t)etween the parent and dependent tables. 

Referential Integrity regulates the deletion of 
rows from the parent table and the addition of rows 
to the dependent table. The foreign key In each s 
row of the dependent table must exactly match the 
primary key of a row in the parent table. 

The referential integrity rule states that the 
foreign key in the dependent table can either be 
null. Le. the dependent row not associated with any iq 
row in the parent table, or it must exactly match 
one of the unique primary key values of the parent 
table. To insert a row Into the dependent table, its 
foreign key value (which points to the parent table) 
must be null or match a primary key in the parent is 
table. 

Enforcement of the integrity rules prevents or- 
phan rows. This Is done by (1) restricting the 
deletion of parent table rows that are pointed to by 
dependent table rows, or (2) by deleting all the 20 
dependent table rows which point to the deleted 
parent table row. or (3) by setting the pointer in the 
dependent table rows to null when deleting the 
parent table row and (4) by prohibiting the insertion 
of dependent table rows that point to parent table 2s 
rows that do not exist. 

STRUCTURED QUERY LANGUAGE 

Data manipulations of the model fall In two so 
major classes, relational algebra and relational cal- 
culus. The relational algebra consists of the set 
operators-union, intersection, and difference, along 
with special operators such as select, project and 
join. Taking one operator with one or more operand ss 
permits producing a new relation as its result. 

Relational calculus stems from predicate cal- 
culus. To query the database, one writes a math- 
ematical logic statement which affinms or denies 
one or more mathematical results. The data ma- 40 
nipulation language Structured Query Language 
(SQL) used for IBM's DB2 systems contains a 
blend of relational algebra and relational calculus. 

With diverse networks, data bases and a vari- 
ety of network management functions used by dif- 45 
ferent organizations wittiin the enterprise with little 
sharing of data between them, we searched for 
ways of establishing a common source for all 
network-related data, enterprise-wide. That search 
ended in the network repository system of the so 
present invention. 

SUMMARY OF THE INVENTION 

The present Invention concerns a novel rela- ss 
tional data base system for managing a data com- 
munications network by searching, addressing, re- 
trieving and manipulating records of tables stored 


in a central repository containing networic Informa- 
tion. 

The records contain functional and physical 
attributes of nodes and links. The functional 
records are stored in tables and are related in a 
relational data t>dse format tiiat models the ar- 
chltectural configuration of the networtt. The phys- 
ical records are also stored in relational tables and 
are used to represent the physical entities compris- 
ing the network. 

* A novel relational data base table employs a 
novel relational key called a nonstandard reference 
(NSR) which is used to relate hinctional records 
with con^espohding physical records. The NSR per- 
mits arbitrary association of networic functional and 
physical entities stored in the central repository 
without disruptions to the searching, addressing, 
retiieval and manipulating capabilities of the man- 
agement system. 

BRIEF DESCRIPTION OF THE DRAWING 

Note: Reference numbers in the figures have 
tiiree or more digits wttii ttie two least significant 
digits representing numbers within \he figure and 
ttie more significant digits representing the figure 
numt>er. 

Fig. 1 depicts in block diagram form a networic 
of an enterprise employing groupings of SNA 
and other types of networic nodes with one of 
tile groupings of nodes (Node t. Domain 1} con- 
taining the repository of tiiis invention; 
Fig. 2 illustrates a relational data base model of 
a communication network of the enterprise of 
Fig. 1 separated into logical (functional) and 
physical tables which Is illustrative of a major 
portion of the repository of this invention; 
Fig. 3 illustrates relational data base tables of 
miscellaneous tables which augment certain 
designated physical tables of Figure 2;^ 
Fig. 4 depicts relational cfata t>ase tables con- 
taining data for use in making changes in the 
state of the network configuration; 
Fig. 5 depicts DBMS table operations using Pri- 
mary Keys (PK). Foreign Keys (FK) and Non- 
standard References (NSR) to perform logical to 
physical mapping using the Physical Implemen- 
tation (Pimpi) table; 

Fig. 6 depicts DBMS table operations using 
PK's. FK's and NSR's for determining which, 
physical tennlnal implements several functional 
termif^ls; 

Rg. 7 depicts DBMS table operations using 
PK's and FK*s for determining the cost of a 
particular modem; 

Fig. a depicts DBMS table operations using 
PK's and FK's for determining ttie model num- 
t>er of several terminals; 
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Rg. 9 illustrates DBMS table operations using 
PK's and FK's to detennine the PU's that con- 
nect to a certain line; 

Fig. 10 depicts DBMS table operations using 
PICs and FK*s to detennine channels on a cer- 
tain T1 node; Rg. 1 1 depicts DBMS table oper- 
ations using PICs and R<'s to determine the 
location of a certain host computer; 
Rg. 12 illustrates DBMS tables using standard 
and nonstandard references to add a CCU to an 
existing line; 

Rg. 13 illustrates a stored SQL query used to 
locate all the CCU'S connected to a certain line; 
and 

Rg. 14 illustrates the display viewed by a user 
who desired the information from the query of 
Rg. 13. 

DETAILED DESCRIPTION OF A PREFE RRED EM- 
BODIMENT " 

With reference to Rg. 1. this figure depicts in 
block diagram form a SNA and other types of 
network element groupings of nodal switches aruj 
communication links of a distributed communica- 
tion network 100 of an enterprise. This grouping of 
nodes in Rg. 1 spans just two domains for illustra- 
tive purposes; however, the principles of this inven- 
tion apply to networks comprising many more do- 
mains. 

Within the groupings of nodal switches and 
communications links, components of a relational 
database repository exist in sub-area 102. A host 
computer 104 and disk drives 106 for mass storage 
of data form the major physical components in 
which the repository resides. 

The host 104 uses a group of IBM Iteensed 
system programs, to perform machine dependent 
system functions, to control the network and to 
operate the repository. Although the repository 
could be located in domain 2 or some other do- 
main, in this illustration it resides in domain 1 . 

Within each domain, one host computer con- 
tains the SSCP NAU. The SSCP. normally one per 
domain, has complete knowledge of, and control 
over type 4. 2 and 1 nodes within the domain. In 
Fig. 1. the SSCP operates in host 104 in domain 1 
and in host 110 in domain 2. These SSCP's reside 
in IBM's Virtual Telecommunications Access Meth- 
od (VTAM) software 108 that controls the flow of 
data to various designated users. 

Host 104 also contains a software operating 
system for large mainframes called Multiple Virtual 
Storage Enterprise Systems Architecture 
(MVS/ESA) 112. MVS/ESA controls the execution 
oi programs. 

Other system programs not considered a part 
of the operating system include utility routines, a 


loader and a translator. The utility routines perform 
frequently used functions needed by many appfica- 
tion programs (programs written by or for the user) 
such as sorting data base relations or copying data 
5 or a program from a tape to disk, etc. 

The loader loads programs into memory for 
' execution. The translators: e-g., a compiler trans- 
. lates high level language programs (COBOU FOR- 
TRAN) into machine language and assemblers 
to translate mnemonics of assembly language pro- 
' grams into machir^ language. 

For repository operations, host 104 emptoys 
other programs such as Database 2 (0B2) 114. an 
. IBM relational data t>ase management system 
76 (ROBMS), that uses SQL for relational data base 
management systems designed to support inter- 
active queries, report writing, and end user com- 
puting; Query Management Facility interface (QMF) 
118, an IBM program, that accesses tables, allows 
20 ad hoc SQL queries, prepares reports and ex- 
ecutes procedures for a series of queries and re- 
ports» and prepares data for graphics in response' 
to suitable input data; Common Business Oriented 
Language (COBOL) compiler 120 a program that 
25 translates COBOL programs into machine lan- 
guage; Customer Information Control System 
(CICS) 124 an IBM program that processes trans- 
actions submitted from a user terminal, accesses 
the proper data bases as dictated by the transac- 
30 tons and displays the results of the transactions on 
the user's terminal. 

In addition to the type 5 nodes. Fig. 1 depicts 
subarea channel links (channel) 128 that connects 
type 4 and 5 nodes, the type 4 nodes being front- 
35 . end processors 130 running Network Control Pro- 
grams (NCR) 132. NCR's provide advanced cono- 
munications functions to PU type 2 (peripheral 
nodes 134 (CCU's, Remote Job Entry units) and 
PU type 1 peripheral nodes 136 (terminals, print- 
40 ers); and peripheral links (cables) 138. low and 
medium speed telecom circuits 140 and high 
speed circuits 142. 

Although DB2 is used in this preferred embodi- 
ment, this invention can t>e implemented using 
46 other true relational data base systems. 

FUNCTIONAL^HYSICAL MODEL 

The repository stores infomnation atx>ut the 
50 SNA network and its nodal switches and commu- 
nication links. However, it k)ecame important to 
allow the repository to store information about all 
network elements regardless of the network ar- 
chitecture used to manage them. That requirement 
55 meant completely separating descriptions of phys- 
ical devices from descriptions of functional entities 
they represent. The distinction between functional 
entities and physical devices is critical because the 
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repository must store Oata in as general a way as 
possible to allow for future growth. While SNA is 
shown, the invention which allows any-to-any con- 
nectivity is applicable to NON-SNA architecture. 
LANS and other OSI based networks as well. A 
network management system (NMS) can view and 
manipulate functional (or logical) entities, but such 
viewing and manipulating has no meaning outside 
of the context of that system since the network 
architecture defines the entities. 

Fg. 2 depicts a logical (functionaiyphysicai dia- 
gram of tables containing an array of information of 
the various nodes and communication links of mul- 
tiple networks similar to the one of Rg. 1. These 
tables, stored in a network repository of a central- 
ized network managament system (CNMS). contain 
data which enable system enterprise management 
of multiple networks. Illustratively, this invention, in 
its presBnx form, pennits managing from a central 
location 15 data centers. 40 FEP's and about 
35.000 devices from a variety of vendors. Services 
provided from this central location include inven- 
tory, configuration, change, accounting and security 
management. 

GENERAL FUNCTIONAL TABLES (GF) 

Fig. 2. upper portion 202. depicts relational 
tables that contain the functional name and related 
information of NAU's and links logically intercon- 
nected according to a network architecture using 
conventional database symbols to depict connec- 
tivity. The upper portion 202 depicts a relational- 
table model of the logical network. 

Note that the relations in the upper portion 202 
show that a host node record from the func host 
table 206 (containing a primary key) may optionally 
connect to one-to-many other host nodes by a 
related record (containing a foreign key) in an 
associative host-to-host table 216. 

Also, the model shows that a host node record 
from the func host table 206 optionally connects to 
one-to-many FEP's by related records in an associ- 
ative Host-To-FEP table 218. The model depicts 
similar relations for tiie other NAU's; i.e. func FEP 
208. func line 210. func CCU 212. func terminal 
214 and hinc RJE 216 tables. RJE's are not NAU's. 
but shown in the upper portion 202 because RJE's 
perform important network functions. 

GENERAL PHYSICAL TABLES (GP) 

The lower portion 204 depicts relational tables 
representing actual physical hardware and subsid- 
iary equipment that implement the NAU's and links 
listed in the upper portion 202. These tables noi 
interconnected in a network architecture scheme, 
connect in a top-down structural manner, using 
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conventional symbols and reference numbers In 
some of the tables, to show relationship with other 
relational tables defined lnfr& 

Note, from a hierarchical point of view, that the 

5 relations in the lower portion 204 show a Tl node 
record from a physical Tl node table 220 has a 
one-to-many connection to a Tl nest table 222 and 
several records In the Tl nest table 222 point to 
the Tl node record of table 220: each Tl nest 

0 record has a one-to-many connection to a Tl slot 
table 224 and many records in the Tl slot table 
224 refer back to a Tl nest record; and each Tl 
slot record requires a one-to-many connection to a 
Tl channel table 226 and records in the physical 

6 Tl channel table 226 refer back to a record in the 
Tl slot table 224. 

MISCELLANEOUS TABLES (Ml) 

» The one (1) in the Tl Node table 220 expands 
infonmation about Tl nodes to Include administra- 
tive information in tfie tables shown in figure 3. 
Additional information about location, financial, 
manufacturer, vendor, service, person in charge of 
f and hardware category of ttie Tl Node exist in 
ttiese tables. 

The same administrative information applies for 
each piece of hardware in the lower tables of Fig. 2 
with a one (1) shown in the box; i.e., such informa- 
30 tion exists in the data base for matrix switch 256. 
printer 288. FEP 294, CCU 293. Host 291 and all 
other hardware with tables that include the (1) 
notation. 

3« IMPLEMENTATION PLAN TABLES (IP) 

The tables of Rg. 4 show how the hardware 
and administrative portions of the data base fit in 
Witt) a request handling portion. The tables of Rg. 4 

40 provide the link behveen implementation plan and 
changes in the state of . the network hardware. The 
two (2) in the Terminal Model Table 286 expands 
infomiation about terminals to include administra- 
tive and change information in the tables shown in 

45 Rg. 4. The same administrative and change in- 
formation applies for each piece of hardware in the 
lower tables of Rg. 2 with a two (2) shown in the 
box; i.e. such information exists in the data base for 
Cable Model 274. Terminal Model 286 and Printer 

so Model 280. These tables perniit adding or deleting 
hardware to maintain the current state of the net- 
work configuration. For each request, there are 
zero-to-many implementation change records, each 
of which, has a non-standard-reference which points 

55 to a record affected by that request. The non- 
standard-relerences and the employment of the 
implementation tables will be explained supra. 
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FUNCTIONAL TO PHYSICAL MAPPING 

The repository permits functional to physical 
device mapping. Mapping refers to relating func- 
tional devices as seen by tfie network management 
system to the pieces of hardware that implement 
them. This is important since a user should have 
means for identifying faulty hardware when a net- 
work problem occurs. Mapping penmtts a user to 
determine whether a physical terminal has a history 
of trouble reports even though the temninal has 
been known by more than one functional name. 

Also, mapping pennits detenmining whether a 
functional entity exists as one or more physical 
entities, or a given functional entity exists phys- 
ically in more than one form, or whether a single 
physical device implements one or more functional 
entities. 

For another case where mapping becomes im- 
portant, consider a network sending data between a 
FEP and a CCU; l.e., from a subarea node to a 
peripheral node. Under SNA. a line represents a 
logical entity because VTAM views tines separately 
from the physical hardware forming the actual path 
between the two devices: and VTAM does not 
maintain any information about the hardware. The 
line has its own SNA identification and SNA char- 
acteristics, such as initial status. These features 
known only by VTAM do not characterize line hard- 
ware. Furthermore, the line may be implemented in 
many ways; e.g., two modems connected to a 
leased circuit, a T1 connection, or a satellite con- 
nection. Each implementation involves several 
pieces of physical hardware, and VTAM doesn't 
know (or need to know) about them. Hence, a SNA 
line (and more generally, any hjnctional entity de- 
fined by an architecture) is independent of the 
physical hardware implementing it. In addition, 
there is no guarantee tiiat a particular type of 
hardware will always implement a particular type of 
logical entity. Therefore, the repository should not 
store a physical element description with any logi- 
cal entity. 

CONNECTIVITY 

The repository deals with functional (logical) 
and physical connections. Functional connections 
relate functional entities to one another; e.g.. in Fig. 
2 a user node (stored in the repository table Func 
Terminal table 214) connects to a host application 
(stored in the repository usage table 231). 

Physical connections relate physical entities to 
each other; e.g.. the cable (stored in repository 
cable table 276) runs between a physical terminal 
(stored in repository table 282) and a cluster con- 
troller table 293 (stored in the repository table 273). 

It is impossible to anticipate future hardware 


configurations. Therefore, the repository must 
maintain connection data in as general a manner as 
possible. Therefore, no assumptions exist about 
what type of device connects to another device. 
5 This generality will allow the repository to maintain 
information also about non-SNA architectures and 
devices when Incorporated. 

; NON-STANDARD REFERENCES 

Most of the repository tables follow standard 
relational theory. However, given the arbitrariness 
inherent in physical connectivity and physicaJ-to- 
logical mapping, a numt>er of relationships have 

16 foreign keys in a dependent table referencing 
records in an arbitrary parent table. Since IBM's 
DB2 does not support such arbitrary references, 
we departed from standard relational theory. This 
departure brought about references, used in this 

20 invention, called non-standard references (NSR's). 
NSR's consist of a parent table name and an 
internal code that refers to a row of that parent 
table. 

25 OBTAINING UNIQUE KEYS 

Every row in the database has a unique key. 
When adding a new row to a table, the row re- 
ceives an assigned, system-generated, unique 
30 number. An application program 119 of Rg. i gen- 
erates It 

STATUS FLAGS 

36 One of the primary functions of the repository 

is to store infomnation about requests lor establish- 
ing connections to the SNA network. Users submit 
requests, and the infonmation concerning the re- 
quest becomes the basis for specifying changes to 
40 tiie state of the network. Until processing is com- 
plete (including installing or removing circuits and 
equipment and updating the appropriate network 
control program), remains "pending". Hence, in 
column 3. for each record in the tables that repre- 
ss sents any part of the configuration of the network 
affected, a status flag shows an "active", 
"pending", or "pending delete" state. The imple- 
mentation plan tables of Fig. 4, mentioned supra, 
permit handling network change requests. 

so 

THE PHYSICAL IMPLE MENTATION TABLE 
(PIMPL) ~~ 

With reference again to Fig. 2, as mentioned 
65 supra, each box in the figure represents a relational 
table. The tables In the lop half store information 
about logical (functional) entities and those in the 
bottom half contain data about physical entities. 
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Because of the many ways to implement functional 
entities, this inventive system provides a way to do 
botfi the following: (a) It given a functional entity, 
find the physical entities that implement it; and (b) 
if given a physical entity, find the related functional s 
entities that it implements. 

Placing functior^al identifiers or foreign keys in 
physical entity tables or vice versa to accomplish 
the above, would require many columns, use ex- 
cessive space and would create an inflexible solu- lo 
tlon. To remedy this problem, the physical Im- 
plementation table or "Pimpr resulted. The reposi- 
tory of this invention makes all references between 
the functional and physical entities via Pimpl. 

With reference to Rg. 2. note the cardinalities is 
represented by the relational symbols pointing to 
PimpL Each physical device is part of zero-to-many 
functional structures and zero-to-many physical de- 
vices implement each functional stnicture. Note 
that the "crow's foot" points to the table, Pimpl, to 
containing a foreign key. Pimpl must include at 
least one foreign key from a functional table and 
one from a physical table. 

PIMPL TABLE ATTRIBLTTES 25 

The Pimpl table, with prestored data, contains 
normally seven columns. Column 1 provides a con- 
nection identifier (an internal code) that uniquely 
identifies a logical/physical association or physical so 
connection. Column 2 presents sequence numbers. 
These numbers represent the connection sequence 
of the hardware that implements the functional en- 
tity. Column 3 contains a status flag. 

The pair, columns 4 and 5, the functional entity ss 
table name column and a numt)er referencing a 
#ow within the named table, form the NSR for the 
functional entity. The functional entity table name 
and the associated foreign key may appear in more 
than one row of Pimpl if more than one piece of ao 
hardware implements that functional entity. 

The pair, columns 6 and 7, the physical hard- 
ware table name(s) column and a number referen- 
cing a row within the named table, form the NSR 
for the physical hardware.. 45 

The NSR of each piece of hardware needed to 
implement the functional entity appears on a sepa- 
rate row of Pimpl. 

APPLICATION OF PIMPL (Functional to Phys ical so 
Mapping) ; 

For an illustrative application of Pimpl. refer 
now to FIG. 5. The top half of Fig. 5 depicts 
GFLINE table 502. an excerpt from functional line 55 
table 210 of Fig. 2, Table 502. a parent table, 
contains 2 records of functional lines. The first 
record has a line-network name of CL12054 and a 


unique primary key (PIC5.12) of 1. The second 
record has a llne-network-name of CL12053 and a 
primary key (PK514) of 2. 

To find the physical hardware implementing 
CL12054, the DBMS looks in Pimpl for the func- 
tional line table (GFLINE) and for the foreign key 
(FK512). The combination of these data elements 
forms a NSR which refer to the parent table. 

The DBMS can now find the physical hardware 
tables, (three tables-in this case), and the primary 
keys (three keys) for these tables. They combine to 
form the NSR's to a record In a parent table of 
physical entities. 

To establish a unique key for each record in 
Pimpl. a connection identifier (l_.IMPL_PHYS) 522 
must combine with a sequence number (l_SEO) 
524 as depicted in table 504 by the (1,1) for the 
first row; (1,2) for the second row, (1.3) for the third 
row and (2.1) for the fourth row. respectively. Note 
that for l_IMPL_PHYS the sequence ex- 

tends from 1 to 3; hence, the physical implementa- 
tion of CL12054 consists of three physical pieces 
of hardware. 

The NSR (the hardware table name and the 
identifying hardware key), "CPMODM" and "1" 
point to a record in Table 506 where the data 
element "1" for foreign key FK 516 references 
"modem 1"; the second NSR, "GPCIRC" and "1" 
points to a record in circuit table 508 where FK517 
references the "circuit 1"; and the third NSR. 
"GPMODM" and "2" points to a row in modem 
table 506 where FK518 references "modem 2". 

ANOTOER APPLICATION OF PIMPL (THREE 
FUNCTIONAL Ef^lTlES REPRESEN TED BY ONE 
PHYSICAL TERMINAL) 

Rg. 6 depicts the tables and data elements 
required to determine the single physical terminal 
that performs the function of tiie three functional 
terminals that VTAM directs. 

GTERM Table 602 presents excerpts of the 
func terminal table 214. This table provides unique 
keys (PK 612. 614. 616 and 618) for four functional 
terminals named under the field entitled 
"N_TERMNL_NTWK". 

To find tiie physical hardware that implements 
the functional terminals TMI8O8O, TM18082, 
TM18084 and TM18088, the DBMS looks in Pimpl 
for the functional (logical) NSR comprised of func- 
tional terminal table names (GFTERM) and the 
foreign keys (FK612. FK614. FK616 and FK618). 

DBMS discovers from the hardware NSR's of 
Pimpl that one NSR, "GPTERM" and "3", points to 
a record in Table 606 where the data element "3" 
of FKe20 shows that the single physical hardware 
terminal number 4281 performs the function of 
three functional (logical) terminals. 
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AN APPLICATION OF NSR WITHOUT THE USE 

OF piMPL ; 

If a user desires to know how much it costs for 
modem serial number 123, an operator may re- 
quest this information from the DBMS. With refer- 
ence to Rgure 7. the DBMS looks at hardware 
modem table 250 and finds primary key PK712 
(the data element « 2) of "modem no. 123" de- 
picted in table 702, table 702 providing excerpts 
from table 250. Then DBMS will refer to the table 
name "GPMODM'and the foreign key FK712=:2 
that form the hardware NSR in table 704, the 
hardware financial table (Excerpts of Table 310 
shown in Table 704). The NSR points to a primary 
key PK714= 2 in the financial table 311 (excerpts 
shown in Table 706) where the foreign key 
PK71 4 = 2 shows that the cost equals $1 00. 

AN APPLICATION WHERE DBMS INTERACTS 
WITH TWO DIFFERENT SETS OF TABLES W ITH> 
OUT THE USE OF NSR'S ' 

If a user desires to know which terminals have 
the model number 3279. the operator will request 
DBMS to look at the hardware terminal model table 
286 (excerpts found in Table 804) for model 3279. 
There, the model number becomes the primary 
key (PKBOS). 

Then DBMS refers to the terminal table 282 
(excerpts found in Table 802) for FK808. FK808 
refers to temninals 3, 4 and 5 which bear the model 
number 3279. 

AN APPLICATION EMPLOYING ONLY F UNCTION- 
AL TABLES 

To find which PU2's connect to line FL14109, 
DBMS refers to the functional Line Table 210 
(excerpts in Table 902) for PK908-1 to line no. 
FL14109. 

Then DBMS refers to FK908= 1 in the Une-To- 
ecu Table 236 (excerpts in Table 904). In the 
l_CCU_FUNCL field of Table 236. DBMS finds 
that FK908=1 refers to five CCU's (FK910=1. 
FK912 = 2. FK914 = 3. FK915 = 4. and FK916 = 5). 
These foreign keys refer to PK910 = 1, PK912 = 2. 
PK914 = 3, PK915 = 4 and PK916 = 5 in the Func- 
tional ecu Table 212 (excerpt in Table 906) which 
indicate that PU2's FC141095, FD141091. 
FD141092. FD141093 and FD1 41094 connect to 
line no. FL14109. 

AN APPLICATION EMPLOYING ONLY PH YSICAL 

TABLES 

To find which T1 channels are on T1 nodes, 
the DBMS looks at the record in the T1 node table 


QPT1ND where l_T1_N0DE is 5 and determines 
that It has PK1014«2. It then finds the record In 
table GPT1NE having a FK10l4»2 (pointing to 
table QPT1ND 1002). II then finds the record in the 

5 GPTISC table having a FK1012s2 (pointing to 
table QPT1NE 1004). It then finds the records in 
the GPT1CH table having a FK1010»3 (pointing to 
table GPT1SL (1006). indicating channels 1 and 2 
. are on Ti node 5. 

fo • 

AN APPLICATION FOR FINDING THE LOCATION 
OF HARDWARE 

To find the location of host computer serial 
16 number 6. DBMS refers to the Host Table 291 
(excerpts in Table 1102) and find PK1102 = 3. 

DBMS refers to FK1102s3 in the Hardware 
Location Table 302 (excerpts in Table 1104) and 
finds FK1106«2. 
20 Then DBMS refers to PK1108 = 2 in Location 

Table 304 (excerpts in Table 1106) and find 
FK1108«1. 

Then DBMS refers to PK1108 in Building Table 
308 (excerpts in Table 1108) and finds host com- 
25 puter serial number 6 on the second floor of the 
Keller Building. 

OPERATION OF THE SYSTEM 

00 To obtain Infonmation from the repository of 
system 100 of Rg. 1, the user enters a SQL query 
at a user terminal such as terminal 136 of Rg. 1. 
Operation of the system can also be through in- 
dividual SQL queries or through COBOL application 

3$ programs at a user terminal such as terminal 136 
of Fig. 1. 

Illustratively, in an effort to troubleshoot the 
network, the user, needing to find which PU 2's 
connect to line CL12054, retrieves a prestored que- 

40 ry such as the one shown in Rg. 13. (Individual 
queries could also be used). 

Using this query. DBMS wilt SELECT columns 
FROM three tables; namely, [parent table] Func 
Line Table 210 [associative table] Line-to-CCU Ta- 

45 bie 236 and [parent table] Func CCU Table 212. 
Excerpts from Func Line Table 210. Line to CCU 
table 236 and Func CCU Table 212 are depicted in 
tables 902. 904 and 906 respectively. 

DBMS uses the WHERE clause, to search for 

50 parent table OFLINE. column N_UNE_NTWK 
where the data element » TL14109'. Then DBMS 
uses one predicate AND clause which refers to 
column l_LINE_FUNCL to yield a PK908= 1 and 
to the associative table Line-to-CCU table 236 coK 

55 umn l_LINE_FUNCL to yield a foreign key 908 - 
1. From this search. DBMS establishes a Uanspar- 
ent join ""A" table as depicted in Table 908. 

Then DBMS uses the other predicate AND 
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Clause which refers to column l_CCU_,FUNCL of 
associative table* Une-to-CCU table 236. to find the 
foreign keys 910 = 1, 912s2, 914=3, 915 = 4 and 
918 = 5. These foreign keys points to the parent 
table Func CCU TABLE 212 and column s 
l_CCU_FUNCL DBMS establishes another trans- 
parent join *B* table as depicted in table 910 
which yields from the N_CCU_NTWK column the 
serial numbers of five CCtJ's. 

Rgure 14 depicts the output display that the lo 
user views at the display terminal. 

Since other modifications and changes varied 
to fit particular operating requirements and environ- 
ments will be apparent to those skilled in the art, 
the invention Is not considered limited to the exam- is 
pie chosen for purposes of disclosure, and covers 
all changes and modifications which do not con- 
stitute departures from the true spirit and scope of 
this invention. 

^ «> 
Claims 

1- A relational data base (RDB) system for man- 
aging a data communications network by 
searching, addressing, retrieving and man- 2s 
ipulating records of tables containing informa- 
tion concerning the network stored in a central 
repository, said data communication network 
comprising network nodes and links defined by 
functional and physical entities and attributes. ao 
said system comprising: 

(a) means for arranging names of functional 
entities along with hjnctional attributes of 
the functional entities in a first set of rela- 
tional database (ROB) tables, said set of ss 
RDB tables related in a manner that models 

the architectural configuration of said net- 
. work: 

(b) means for arranging names of physical 
entities along with physical attributes of said 40 
physical entities in a second set of RDB 
tables: 

(c) means for forming a physical implemen- 
tation RDB table which relates said first set 

of RDB tables to said second set of RDB 45 
tables, said physical implementation RDB 
table employing a chosen form of reference 
that associates specific functional entity 
names and attributes recorded in said first 
set of RDB tables witti specific physical so 
entity names and attributes recorded in said 
second set of RDB tables; 

(d) storage means for containing said func- 
tional, physical and physical implementation 
ROB tables in a manner forming a tabular ss 
repository of named entities and atuibutes 

of said network; and 

(e) computer means programmed to penmit 


using said functional, physical and physical 
implementation RDB tables stored In said 
repository to determine structure and Integ- 
rity of the network as well as to determine 
how to arrange said network to reestablish 
lost integrity and/or to configure said net- 
wori< to a different fbnn. 

2. System in accordance witii claim 1 also includ- 
ing (1) means for arranging names along with 
attributes of admtnisti^ative characteristics as- 
sociated with a first group of the physical en* 
titles and attributes named in said second set 
of RDB tables and (2) means for arranging 
names atong with attributes of other admin- 
isti-ative characteristics associated with at- 
uibutes of adminlsti^ative characteristics of a 
second group of the physical entities and at- 
tributes named in said second set of ROB 
tables. 

X System in accordance with claim 1 wherein 
said first set of RDB tables Include a plurality 
of parent tables and a plurality of associative 
tables which are dependent tables with respect 
to said parent tables, wherein said parent ta- 
bles contain a primary key for each record 
listed therein and wherein said associative ta- 
bles contain at 'least a pair of foreign keys for 
each record listed ti)erein. said pair of foreign 
keys pointing to two parent tables of said first 
set of RDB tables. 

4. System in accordance witti claim 3 wherein 
said second set of RDB tables include a plural- 
ity of parent tables having primary key for 
each record listed ttierein. 

5. System in accordance with claim 4 wherein 
said physical Implementation RDB table con- 
tains records that join names of a table of said 
first set of RDB tables and a foreign key of a 
record tiierewithin said tables witii related 
names of tables of said second set of RDB 
tables and a foreign key of a record therewithin 
to permit said computer means to determine 
which one or many physical entities and at- 
tributes are needed to implement a selected 
functional entity and attribute or vice versa, 
said name of said tables and said foreign key 
of said record in said names of said tables 
forming a nonstandard reference (NSR). 

6. System in accordance with claim 5 wherein 
said computer means contain programs which 
permit an operator to access said repository 
using a structured query of a chosen language 
to: (a) find the physical entities that implement 
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a functional entity: (b) find administrative at- 
tributes of a physical entity; (c) find the func- 
tional entity associated with another functional 
entity; (d) find physical entity associated with 
other physical entities; (e) find the logical entity s 
that a pliyslcal entity Inrtplements; (0 find all 
the devices at a specified location; (g) find the 
devices for a specific manufacturer or vendor; 
(h) find all devices under a spedfic service 
agreement: and (i) find all the devices for lo 
which a specific contact person is responsible. 

7. A method of forming a relational data base 
(RDB) system for managing a data commu- 
nication network by searching, addressing, re- rs 
trieving and manipulating records of tables 
containing Information concerning the network 
stored in a central repository, data communica- 
tion network comprising network nodes and 
links defined by functional and physical entities 20 
and attributes, said method comprising the 
steps of: 

(a) gathering tabular records of the physical 
and functional entitles and attributes of the 
nodes and links forming the network as well 2s 
as administrative data associated with each 
physical entity in the network; 

(b) preparing a relational data base model 
of the network wherein said model sepa- 
rates the functional entity and attribute 30 
records from the physical entity and at- 
tribute records of the network, wherein said 
functional records are related in a manner to 
depict the architectural structure of the net- 
work and wherein said model design in- as 
eludes a physical implementation ROB table 
which links specific records of a functional 
entity tiiat is implemented by a specific 
physical entity or combinations of physical 
entities or vice versa; 40 

(c) storing in a data mempry said functional 
records as parent and associative RDB ta- 
bles wherein said parent fables contain pri- 
mary keys and said associative tables con- 
tain foreign keys refeningjto at least two of 4s 
said parent tables containing said primary 
keys In a manner that rotate the architec- 
tural arrangement of the network to the ar- 
rangement of the functional records; 

(d) storing in the same data memory groups so 
ofrelated records of said physical records 

as parent tables, wherein said groups are 
stored in arbitrary tables; 

(e) storing in the same data memory the 
physical implementation records as depen- 55 
dent tables of functional records containing 
foreign keys and physical records also con- 
taining foreign keys, wherein said functional 


records dependent directly upon a physical 
record or a group of physical records that 
provide Information regarding the Imple- 
mentation of a functional entity described in 

said functional record; 

(0 preparing an RDB model of administra- 
tive records that form an addendum to se- 
lected tables of said physical records stored 
as primary tables* said addendum providing 
physical entity location, finandal. manufac- 
ture, vendor, seryioe. person and category 
information, said addendum also providing 
means for implementing changes to said 
primary functional and physical tables and 
said associated functional tables as well as 
said dependent implementation tables: 
(g) after providing a computer means, stor- 
ing application program means in said com- 
puter means that permit using said func- 
tional, physical, administrative and physical 
implementation RDB tables In said memory 
to determine structure and* integrity of the 
network as well as to determine how to 
an-ange the networic to reestajDlish lost in- 
tegrity and/or to configure said network to a 
different form. 

& The method of claim 7 wherein said applica- 
tion program means Include means for using 
Structured Query Language (SQL) for commu- 
nicating with said RDB and means for provid- 
ing screen display on a terminal of resulting 
tables. 
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3(FIC1010) 2 
4 1 
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1008 


Trie 


3.1 □. 
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gPHPST 


2 I 

CPR05T HDm 

X 4 

2 5 

)(PK110a) 6 
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1102 


Z 

KDWE 
Log 

1 
2 
3 
4 


N 

HOUE 
TBL, 

(GPHOST 
[GPCZKC 
[GPHOST 
[GPK0ST(1104) 


Z 

HOWE 


1]MSK 
X]NSR 
2]NSR 

2(FX1102}]NSR 
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1104 


CLgCM, 


I 

3 
1 
1 

2{Pxiioe) 


z 


2(PX1106) 


Z 

m 

1ST FLR 
2KD FIJI 
1ST FLR 


Z 

AL&S 

1(PXX108) 
1(FX1108) 
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(EXCERPTS FROM LOCATION TABLE 304) 

llOi 


SSU3SL 


Z 

fiLQfi 
1(PK1108) 
.3 


H 

UDfi 

KELLER 

HIS 

ENG 
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CIMPPL GPLIWH 

» C tINB LZME C 

STKt FWCL KTWK . STXT 

22*HJ ® 821(FKX202) CUIOSS X 

90*123 e 

(EXCERPTS VRXm ZMPLEHENTAXXON (EXCERPTS FROM FUKC UHB TA8&B 210} 
PiAM TABLE 404) ' 

1202 1204 


CPCCU 

M 

ecu c 

tWWK STAT 
123(?K1204) CW00161 P 

(EXCERPTS FROM FUNC CCU TABU 212} 

1206 

CL2CCU 
Z 

LIMB Z Z 

ecu ecu LZME C. 

COWH FUWCL FOMCL STAT 

12a0(PK1206) 123(FKI204) 821(FK1202) P 

(EXCERPTS FROM LIME TO CCU TABLE 236) 

1208. 

GIMPCH 
Z 

SRVRO M I 

TP TBL KEY 

90-123 cerccu 123 j msr 

90-123 (CL2CCU 1280] MSR 
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1210 


ISOOCIO: <EP 0S0711QA2J.» 


EP 0 507 110 A2 


SELECT G.GFLZNE.M.LZMEJITWK 
, G.OFCCV.HJCCU.HTWK 
FROM G.GFLIME 
, G.GL2CCU 
, G.GFCCU 

VHERS (6.GFLZNB.M.LZME_llTVaC s *FL14109*) 

AND (G.6L2CCU.I_CCU_FUNCt = G.GFCCU. I_CCU_FUNCL) 
AND (G.GL2CCU.Z_LINE.FUNCL = G.GFLIME. I_LINE_FUNCL) 

ORDER BY G.GFLIME. M.LZKEJNTWK 
G . GFCCU . N_CCUJNTWK 
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